Does this mean we'll use Guard, GuardMut instead of ReadGuard, WriteGuard for reader-writer locks (with GuardMut also serve as the guard for exclusive locks)? This is slightly different from other Rust lock designs but I think is reasonable.

Does this mean we'll use Guard, GuardMut instead of ReadGuard, WriteGuard for reader-writer locks (with GuardMut also serve as the guard for exclusive locks)? This is slightly different from other Rust lock designs but I think is reasonable.

This is a different dimension: the guard for the write-side critical section of a sequential lock only exposes immutable references to the underlying data. So if we were to use ReadGuard and WriteGuard, the write method of a lock would be returning a ReadGuard, which isn't very intuitive. I think the mutable vs immutable distinction (as in Iter/IterMut and Cursor/CursorMut) seems more descriptive and we have precedents of their use.

I'm not really a big fan of the Mut suffix though. If you have better ideas, I'd be happy to change.

Seqlocks probably require their own abstraction, e.g. https://docs.rs/seqlock/. (I would probably change the read method to take the signature pub fn read<U>(&self, f: impl FnMut(T) -> U) -> U)

Seqlocks probably require their own abstraction, e.g. https://docs.rs/seqlock/. (I would probably change the read method to take the signature pub fn read<U>(&self, f: impl FnMut(T) -> U) -> U)

The seqlock in the kernel behaves differently, we don't necessarily want (and can't in some cases) copy a whole T out of the lock. Anyway, the read side is definitely different enough that we don't want to try to merge it into the existing abstractions, but the write side is very much conventional -- ideally it should work as a lock for CondVar and LockedBy.

I am not sure if exposing immutable references to seqlock write side is the correct abstraction.

I think it's better a have the better picture of seqlock API design before renaming this.

I am not sure if exposing immutable references to seqlock write side is the correct abstraction.

Unlike rwlock, for seqlock (and RCU), read side and write side are not mutually exclusive, so the uniqueness of the references in the write side cannot be guaranteed.

I think it's better a have the better picture of seqlock API design before renaming this.

I agree. Having some POC code definitely help discussion. @wedsonaf I think you actually have the draft implementation already?

I wonder whether we can add "mutability" to interior mutable type? Something as the following:

pub struct NonRaceUsize {
    val: AtomicUsize
}

impl NonRaceUsize {
    pub fn store(&mut self, v: usize) {
        self.val.store(v, Ordering::Relaxed);
    }
    
    pub fn load(&self) -> Usize{
        self.val.load(Ordering::Relaxed);
    }
}

Will it still be UB if we have (and access) both &mut NonRaceUsize and &NonRaceUsize at the same time?

Unlike rwlock, for seqlock (and RCU), read side and write side are not mutually exclusive, so the uniqueness of the references in the write side cannot be guaranteed.

In LLVM there is an "unordered" ordering that is more relaxed than "relaxed" ordering; it basiscally is a non-atomic access that is defined to be not UB when data race happens. So it's okay if one side is having mutable access and another is only performing "unordered" read access. There is some use of it in compiler builtins but since it's a LLVM thing and not formally defined in Rust so we definitely want to avoid it.

Will it still be UB if we have (and access) both &mut NonRaceUsize and &NonRaceUsize at the same time?

It would still be UB under Rust memory model.

I had this idea: https://godbolt.org/z/63qsTsave

There are tons of scaffolding, but the usage is really just the last few lines. The key idea is to use &mut ZST to represent the permission to the whole struct.

Unlike rwlock, for seqlock (and RCU), read side and write side are not mutually exclusive, so the uniqueness of the references in the write side cannot be guaranteed.

In LLVM there is an "unordered" ordering that is more relaxed than "relaxed" ordering; it basiscally is a non-atomic access that is defined to be not UB when data race happens. So it's okay if one side is having mutable access and another is only performing "unordered" read access. There is some use of it in compiler builtins but since it's a LLVM thing and not formally defined in Rust so we definitely want to avoid it.

Or formally define it? ;-) Rust definitely don't want to rely on a particular feature of the backend, but can ask the backends to provide certain guarantee, right?

The basic idea is that data races are fine as long as the value of a raced read is never "used", seqlock is one example: reads are considered to be correct only when sequence counts are stable (during begin and retry), which means we are racing with a write side critical section (in memory effects).

That said, the proper definition of "used" may be challenging, there are cases in Linux kernel where a value of a raced read is used: 1) for diagnostic code, which doesn't care that much about correctness, 2) fast check for whether a fastpath can be used, e.g. if (raced_val) { fastpath_will_reread_value_with_locks(...); }, etc.

BTW, the implementation of https://docs.rs/seqlock/ also has UB, right?

BTW, the implementation of docs.rs/seqlock also has UB, right?

Technically yes. Practically, it couldn't be exploited by the compiler. The volatile read is essentially used to mimic the unordered load; it'll be UB-free if unordered load is used (at least according to LLVM semantics).

I had this idea: https://godbolt.org/z/63qsTsave

There are tons of scaffolding, but the usage is really just the last few lines. The key idea is to use &mut ZST to represent the permission to the whole struct.

Try to see if I understand your point, it works because current Rust memory model allows the coexistence&mut ZST and &ZST so it's not UB, and since the real accesses are implemented by atomic, therefore no data race, therefore no UB?

it works because current Rust memory model allows the coexistence&mut ZST and &ZST so it's not UB

Yes. Two pointers alias if the memory regions they point to overlap. Since ZST pointers point to a memory region of 0 bytes, if cannot alias with any pointer by definition.

and since the real accesses are implemented by atomic, therefore no data race, therefore no UB?

Yes

I am not sure if exposing immutable references to seqlock write side is the correct abstraction.

Unlike rwlock, for seqlock (and RCU), read side and write side are not mutually exclusive, so the uniqueness of the references in the write side cannot be guaranteed.

I think it's better a have the better picture of seqlock API design before renaming this.

I agree. Having some POC code definitely help discussion. @wedsonaf I think you actually have the draft implementation already?

Here's the commit for the seqlock: f0e3f12

I had this idea: https://godbolt.org/z/63qsTsave

There are tons of scaffolding, but the usage is really just the last few lines. The key idea is to use &mut ZST to represent the permission to the whole struct.

I like the idea of using a ZST, but how is one supposed to use this? Please don't tell me we need a proc macro to parse type definitions and generate all this code.

I opened #537 so that we can investigate other designs for seqlocks. For now I'll submit this one and we can replace it later if we find a better one.